• 菜雞行為：把「昨天測過會動」當成完成證據
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何把一次性成功改成可重現、可觀察與可驗收的證據鏈。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 20｜我真正要證明的，不是 API 回成功，而是事情完成，把任務定成每層狀態都有可觀察證據。本篇交代我補了什麼、為何照這個順序、哪裡仍不敢保證。

沒有識別碼，Log 再多都對不起來

繼續用虛構的粉鳥工單服務。第一件事不是狂加 Log，而是讓每次匯入請求進系統時拿到關聯識別碼，走過 API、佇列、背景工作程式到狀態查詢。少了它，Log 再多也只是碎片。

[API] --> [佇列] --> [背景工作] --> [狀態查詢]
    同一個關聯識別碼貫穿全程紀錄

有了它，任何紀錄都對得回同一次請求。

再來才是狀態、必要 Log 與測試紀錄

接著依序補三件事。先把 Day 20 定義的狀態落實成狀態表，讓查詢介面與背景工作程式讀寫同一份資料；成功那筆記下匯入幾筆，取消寫成獨立狀態，不是靜靜消失。再替每個狀態轉換留一筆 Log，只記事件、識別碼、結果與失敗原因；個資欄位改記代碼並另訂保留期限。最後把驗收用的手動測試照 Day 19 的《測試證據表》留成紀錄並附識別碼。

失敗可以定位了，但沒有事件的地方還是暗的

結果只寫敢支持的部分。有人來問匯入好了沒，我給編號讓對方自己查，查詢、Log 與測試紀錄說同一個故事；失敗能沿識別碼找到斷點。我沒有數字證明省時。Day 20 訂的四件事裡，狀態、筆數、失敗與取消都留下了證據；通知那條還沒接進同一份狀態，是這輪最明顯的缺口。其餘限制也得承認：佇列塞爆、背景工作程式靜默當掉這類沒有事件可記的情境，只能靠逾時推斷；監控告警還沒建。

粉鳥工程筆記：最小證據集合，從識別碼開始

• 順序：關聯識別碼、狀態、必要 Log、測試紀錄。
• 每筆 Log 要答得出哪次請求、哪個狀態、為何失敗。
• 個資不進 Log；必要時遮罩並訂保留期限。

今天可以帶走的練習

挑一條跨兩個以上服務的流程，花四十分鐘列出最小可觀測集合：每個事件的必要欄位、關聯識別碼、層級與敏感資料處理，產出一頁規劃，由另一位讀者依表回答「失敗去哪找原因」驗收。單一服務、可直接重跑的小工具不必填。

對應工具：《可觀測性規劃表》。

# 可觀測性規劃表

用途：替一條跨服務流程規劃最小必要的事件、欄位與關聯識別碼。
使用時機：失敗要能定位、完成要能交接，而 Log 又不能無限加時。

| 事件 | 必要欄位 | 關聯識別碼 | 層級 | 敏感資料處理 | 保留期限 |
| --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |

提醒：只記會影響判斷的事件；個資與 Token 不進 Log。

下一篇

證據齊了，我一度以為這就叫交付；結果程式碼一交出去，別人還是接不起來。下一條彎路是 Day 22｜程式碼交出去後，我才發現別人根本接不起來。